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Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 
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1. Abstract 


This document examines the problems associated with use of MIME 
security multiparts and gateways to non-MIME environments. A set of 
requirements for gateway behavior are defined which provide 
facilities necessary to properly accomodate the transfer of security 
multiparts through gateways. 


2. Requirements Notation 


This document occasionally uses terms that appear in capital letters. 
When the terms "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 
appear capitalized, they are being used to indicate particular 
requirements of this specification. A discussion of the meanings of 
the terms "MUST", "SHOULD", and "MAY" appears in RFC 1123 [2]; the 
terms "MUST NOT" and "SHOULD NOT" are logical extensions of this 
usage. 


3. The Problem 


Security multiparts [RFC-1847] provide an effective way to add 
integrity and confidentiality services to protocols that employ MIME 
objects [RFC-2045, RFC-2046]. Difficulties arise, however, in 
heterogeneous environments involving gateways to environments that 
don’t support MIME. Specifically: 


(1) Security services have to be applied to MIME objects in 
their entirety. Failure to do so can lead to security 
exposures. 
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For example, a signature that covers only object data and not 
the object’s MIME labels would allow someone to tamper with 
the labels in an undetectable fashion. Similarly, failure to 
encrypt MIME label information exposes information about the 
content that could facilitate traffic analysis. 


Composite MIME objects (e.g., multipart/mixed, message/rfc822) 
also have to be secured as a unit. Again, failure to do so 
may facilitate tampering, reveal important information 
unnecessarily, or both. 


Gateways that deal with MIME objects have to be able to 
convert them to non-MIME formats. 


For example, gateways often have to transform MIME labelling 
information into other forms. MIME type information may end up 
being expressed as a file extension or as an OID. 


Gateways also have to take apart composite MIME objects into 
their component parts, converting the resulting set of parts 
into whatever form the non-MIME environments uses for 
composite objects. Failure to do so makes the objects unusable 
in any environment that doesn’t support MIME. In many cases 


this also means that multi-level MIME structures have to be 
converted into a sequential list of parts. 


Security services have to be deployed in an end-to-end 
fashion. Failure to do so again can lead to security 
exposures. 


An integrity service deployed at something other than a 
connection end point means a region exists between the point 
where the integrity service is applied and the actual end 
point where object tampering is possible. A confidentiality 
service deployed at something other than a connection end 
point means a region exists where the object is transferred in 
the clear. And worse, distributed private keys are usually 
necessary whenever someone other than the originator applies 
an integrity service or someone other than the recipient 
removes a confidentiality service, which in turn may make 
theft of private key information a possibility. 


All of these issues can be addressed, of course. For example, 
it may be possible to use multiple overlapping security 
services to assure that no exposure exists even though there 
is no end-to-end security per se. And keys can be distributed 
in a secure fashion. However, such designs tend to be quite 
complex, and complexity in a security system is highly 
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undesireable. 


The preceeding three requirments are fundamentally in conflict: It is 
possible to satisfy two of them at once, but not all three at once. 


In fact the conflict is even worse than it first appears. In most 
situations of this sort some sort of compromise is possible which, 
while not satisfying any of the requirements completely, does 
optimize some sort of average of all the requirements. Such a 
solution does not exist in this case, however, because many real 
world situations exist where any one of these requirements absolutely 
must be satisfied. 


4. Solving the Problem 


Since the previously described problem doesn’t allow for a single 
solution the only viable approach is to require that gateways provide 
multiple solutions. In particular, gateways 


(1) MUST provide the ability to tunnel multipart/signed and 
multipart/encrypted objects as monolithic entities if there is 
any chance whatsoever that MIME capabilities exist on the 
non-MIME side of the gateway. No changes to content of the 
multipart are permitted, even when the content is itself a 
composite MIME object. 


This option must be provided so that entities behind the 
gateway that are capable of processing security multiparts and 
their MIME content will work properly. As mentioned 
previously, situations exist where application security 
requirements are absolute and must be accomodated, even when 
meeting them causes problems for other agents. 


Exceptions are allowed only when there is no possibility of 
MIME support on one side of the gateway. For example, a 
gateway to a voice messaging system may have no useful way to 
represent a signed MIME object. 


(2) MUST provide the ability to take apart multipart/signed 
objects, exposing the content (and in the process ruining the 
signature). When this approach is selected, gateways SHOULD 
NOT remove the signature. Instead, gateways SHOULD keep the 
signature intact and add to it a note that it will probably be 
invalid for checking the message contents, but may still be 
contain valuable information about the sender. 
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This option must be provided so that entities behind the 
gateway which are incapable of processing MIME will work 
properly. 


SHOULD provide the ability to select between the previous two 
options on per-user basis. 


MAY provide facilities to check signatures and decrypt 
encrypted content. Such facilities MUST NOT be enabled by 
default; the potential security exposure involved has to be 
assessed before such capabilities can be used. 


MAY provide facilities to sign and/or encrypt material passing 
from the non-MIME side to the MIME side of the gateway. Again, 
such facilities MUST NOT be enabled by default; the potential 
security exposure involved in the transfer of unsecured 
content within the application domain behind the gateway has 
to be assessed before such capabilities can be used. 


A gateway which complies with the above requirements is considered to 
be security multiparts compliant. 


5. Security Considerations 


This entire document is about security. 


Freed 
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8. 


Full Copyright Statement 
Copyright (C) The Internet Society (1999). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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